Store result cache paths relative to the install location - #6190

Makes the result cache portable across a change of the project's absolute path prefix (a fresh CI checkout dir, a git worktree). Today the cache stores absolute paths everywhere (meta, storage keys, stored objects) and compares metadata with a strict whole-array match, so a moved project with an identical relative layout throws the whole cache away.

Approach

• Anchor: the phpstan install location (%rootDir%, the phar's directory, or the source checkout under bin/phpstan). This is the anchor @ondrejmirtes landed on: a Composer-installed phar sits at a fixed offset inside the project (vendor/phpstan/phpstan), so the path from the anchor to the analysed code is stable across checkouts and worktrees.
• Error relativizes/absolutizes its own paths (per @ondrejmirtes' note), building on its existing immutable changeFilePath() pattern. A new ResultCachePathTransformer handles the rest of the cache structure (meta, dependencies, the compound linesToIgnore keys, projectConfig) using ParentDirectoryRelativePathHelper to relativize and FileHelper::absolutizePath() to invert. The transform lives at the I/O boundary: save() relativizes before writing, restore() absolutizes right after require; the rest of the manager keeps working in absolute paths.
• ccache's rule. Only paths reachable from the anchor become relative; a path with no shared prefix (a global stub, an out-of-tree dir) stays absolute, and absolutize passes an already-absolute path through unchanged, so relative and absolute entries coexist safely.
• Cross-OS. Stored paths always use /, so a cache written on Windows is usable on Linux and vice versa; on load they are absolutized back to the OS-native separator FileFinder uses for the analysed-file keys. Namespace separators in class names are left untouched.
• Always on, not a toggle (per review). Not a BC break: on the same machine the relativized paths re-absolutize to the identical absolute paths, so behaviour is unchanged; the only difference is that a moved project reuses the cache instead of discarding it. CACHE_VERSION is bumped so old caches migrate with one cold run, and every result cache e2e now exercises the new path.

Covered surface

Storage: errors, locallyIgnoredErrors, linesToIgnore/unmatchedLineIgnores (including the compound path (in context of class X) keys), collectedData, dependencies, packageDependencies, exportedNodes, projectExtensionFiles. Meta: analysedPaths, scannedFiles, composerLocks, composerInstalled (including nested install_path), executedFilesHashes, stubFiles, and projectConfig paths/tmpDir.

Verified by grepping a real self-analysis cache: 0 absolute project-prefix paths remain.

Tests

• e2e/result-cache-relative-path: a cold run stores the analysed file relative to the anchor (asserting the absolute checkout path is absent), and a warm run reuses the cache with 0 files reanalysed.
• A second entry creates a git worktree at a different absolute path with its own vendor, carries the warm cache over, and asserts it is reused there with 0 files reanalysed; then removes the worktree and re-runs in the original checkout to confirm that is still reused.
• I also verified a real cross-prefix move by hand: copying a warm project to a different absolute path reuses the cache, whereas on 2.2.x the same move reports metadata do not match: projectConfig, analysedPaths, executedFilesHashes and re-analyses everything.

Open question: the anchor

%rootDir% is portable when the phar moves with the project (Composer install, worktree, CI checkout). A globally-installed phpstan.phar outside the project tree does not share a moving prefix, so its relative offsets would not survive a move. %currentWorkingDirectory% moves with the project in those same scenarios and matches the issue's wording, at the cost of not covering PHPStan's own stub and config paths. The anchor is isolated behind getPathTransformer() plus the injected %rootDir%, so switching is a one-line change if preferred.

Follow-ups (not in this PR)

• projectConfig excludePaths (stored as OptionalPath objects) is not relativized yet, so a project relying on optional excludePaths still invalidates on a move.
• Opaque ResultCacheMetaExtension hashes and collector payloads that embed absolute paths cannot be seen into by a core transform; the Symfony container extension already folds kernel.project_dir into its meta hash and would need its own handling.
• Symlinked or monorepo layouts where two distinct files could alias to one relative key (normalizePath() is lexical and does not resolve symlinks).
• A bare git worktree whose tmpDir has no cache would need PHPStan to discover the main checkout's cache. This PR makes the cache content portable; that discovery is a separate step.

Closes phpstan/phpstan#8599